The Simple Network Management Protocol (SNMP) was developed to manage various elements in the Internet and attached networks. SNMP uses a manager and agent architecture, wherein each managed device runs an agent from which the manager can obtain information that is provided to facilitate remote management. As illustrated in FIG. 1, an SNMP communication environment 10 is illustrated as having a network management system (NMS) 12 adapted to manage any number of managed devices (MDs) 14, which may represent any type of network element such as personal computers, servers, routers, switches, and the like. The NMS 12 provides a human interface for the overall management system, and is able to communicate with the various managed devices 14. The managed devices 14 each provide an agent 18, which provides an interface between the NMS 12 and the managed device 14 to be managed.
To facilitate management of the managed devices 14, the NMS 12 and the managed devices 14 will use a management information base (MIB) 20 and a small set of commands to exchange information. The MIB 20 is organized in a tree structure, with numerous objects represented at the end of each branch. Each object may be associated with one or more object instances, such as metrics, labels, or other information relevant to managing the network or the managed device 14. The object instances may be operational metrics or a function provided by the managed device 14. An object identifier (OID), which is a long numeric tag separated by periods, is used to distinguish each object in the MIB 20 and is used in SNMP messages to identify the object instance or instances corresponding to a given object.
In general, SNMP uses five basic messages to communicate between the NMS 12 and the agent 18 in the managed device 14. These messages include GET, GET NEXT, GET BULK, SET, and TRAP. The GET, GET BULK, and GET NEXT messages allow the NMS 12 to request information or object instances for a specific object or table of objects. The agent 18, upon receiving a GET, GET BULK, or GET NEXT message, will issue a response message to the NMS 12 with either the information requested or an error message indicating why the request could not be fulfilled. The SET message allows the NMS 12 to request a change to be made to an object instance of an object that allows read/write access. The agent 18 may respond with a response message indicating that a change has been made or an indication as to why the change could not be made. The TRAP message allows the agent 18 to dynamically inform the NMS 12 of significant events. In general, the GET, GET BULK, GET NEXT, and SET messages are sent by the NMS 12. The response and TRAP messages are provided by the agent 18, wherein the TRAP message is the only message that can be initiated by the agent 18.
Each agent 18 in the managed device 14 will manage various objects, wherein each object has one or more object instances that correspond to metrics, variables, or characteristics associated with the object. As noted, each object or object instance has a unique OID consisting of numbers that are separated by periods. An exemplary tree structure for a MIB 20 is illustrated in FIG. 2. The MIB 20 may associate each OID with a label, such as “organization” and various other object instances related to the object. The MIB 20 serves as a reference from which to assemble and interpret SNMP messages.
When an NMS 12, which contains MIB 20, wants to know the information associated with an object or object instance, a GET message is sent including the OID, from MIB 20, associated with the object or object instance being requested. The agent 18 in the managed device 14 will have a corresponding MIB 20, and will use the MIB 20 to identify the object or object instance associated with the OID. Information associated with the object or object instance is then provided back to the NMS 12 in a response message. In the illustrated tree structure, the first level of the OID includes objects CCITT, ISO, and ISO.CCITT, which are associated with OID indexes of 0, 1, and 2, respectively. Under the ISO object, ORGANIZATION, DoD, and INTERNET objects are provided, with OID references 4, 6, and 1, respectively. As such, the OID for the INTERNET object is 1.4.6.1.
Underneath the INTERNET object are DIRECTORY, MANAGEMENT (MGMT), EXPERIMENTAL, PRIVATE, and SECURITY objects, which are associated with OID references 1, 2, 3, 4, and 5, respectively. The OID for the DIRECTORY object is 1.4.6.1.1. Further, the PRIVATE object branches into ENTERPRISE, NORTEL, and OVERLOAD ALARM objects, which have OID references of 1, 8, and 20, respectively. As such, the OVERLOAD ALARM object has an OID of 1.4.6.1.4.1.8.20. The tree can continue with other objects and object instances.
Accordingly, the MIB 20 provides a data structure index corresponding to various objects. Each object will have one or more object instances associated therewith. When a single instance is associated with an object, only one piece of information is associated with the object. When multiple object instances are associated with an object, multiple pieces of information may be associated with an object. These additional object instances may be returned as a group in response to a request associated with that object, or the various instances may be associated with further OID references, wherein each piece of information can be obtained individually. When multiple object instances are associated with an object, corresponding information is associated with a table, such that an OID may correspond to an entire row in a table or a specific entry in a table.
Regardless of whether there are single object instances or multiple object instances provided in a table, existing MIB configurations require each of the managed devices 14 and the NMS 12, which are an associated group, to have the same and comprehensive MIB definitions. As such, if any new objects or object instances are to be gathered, monitored, or otherwise used in the group, a new MIB 20 must be created and provided to the NMS 12 and each of the managed devices 14. As networks evolve and the capabilities of managed devices 14 increase, the MIBs 20 for various systems must be updated frequently. Such updating is cumbersome and manually intensive, as the MIBs 20 are generally manually provisioned at each affected device.
Accordingly, there is a need for a technique by which managed devices 14 can add new objects or object instances without requiring a new MIB definition prior to or after adding the new information. There is a further need to allow the NMS 12 to recognize and retrieve information associated with new objects and object instances, which are added by one or more managed devices 14 without MIB updates.